The World Wide Web and its ever-growing population and acceptance have developed a standard way of addressing information. Typically, the web browser sends a file request to a host server that, in turn, “serves up” the file to the user.
This is achieved using the Internet's underlying architecture, which is built on a foundation of HyperText Transfer Protocol (HTTP) or HyperText Transfer Protocol Secure (HTTPS), Transmission Control Protocol (TCP) and Internet Protocol (IP). In accordance with this set of protocols, a server program on a web server “listens” for a client program (a client web browser) executing on a client computer to connect. The client browser connects to the server by utilizing a Uniform Resource Language (URL). A URL consists of a protocol specification (e.g. HTTP, FTP), a host destination, and a file specification. The host destination is effectively an address for point-to-point communications.
This typical Internet communication is illustrated in FIG. 1. In particular, FIG. 1 illustrates a system diagram of a browser, web server and application server of the prior art. FIG. 1 includes web browser 11, Internet 13, server 15, servers 15.1–15.5, database 17 and content server 19. As shown server 15 includes files 16.1–16.n and executable 18. Moreover, servers 15.1–15.5 can also include files 16.1–16.n and executable 18 (not shown), which is described in more detail below. Web browser 11 is coupled to servers 15 and 15.1–15.5 through Internet 13. In operation, web browser 11 submits a call through Internet 13 to one of servers 15 and 15.1–15.5. An example of such a call could be “http://www.rv.tibco.com/whitepaper.html”. This call includes the protocol specification (http), a host address (www.rv.tibco.com), which is the address of server 15 and a file specification (whitepaper.html).
Typically, server 15 processes this call as a file-based lookup. The requested file is then returned by server 15 through Internet 13 to web browser 11 as an HTTP compliant file, as, for example, a web page. Server 15 can return the file directly to web browser 11 or process the requested file and return the results of the processing. The processing of the file could, for example, result in a call to database 17 and/or an accessing of the file from content server 19.
Thus, the client, web browser 11, sets up a two-way or point-to-point communication with server 15. The communication is established by web browser 11 sending an HTTP request to server 15. In the example of the call for “http//www.rv.tibco.com/whitepaper.html”, server 15 (at “www.rv.tibco.com”) interprets this request as a GET and determines that the client (web browser 11) wants a file named “whitepaper.html”. Effectively, therefore, the call “http://www.rv.tibco.com/whitepaper.html” is a file pointer where “whitepaper.html” is a file stored on the server www.rv.tibco.com that is to be retrieved using the HTTP protocol. Moreover, in the absence of the suffix “whitepaper.html”, the call “http://www.rv.tibco.com” is a file pointer that is interpreted as a GET call of a default page, Typically “index.html” on the server “www.rv.tibco.com”. As illustrated by FIG. 1, current Internet (HTTP/HTTPS/TCP/IP) architecture centers on a filed-based web server that is reliant on a point-to-point communication between the client and the server.
File-based architectures combined with ever growing needs for expansion of 7-days-a-week-by-24-hours-a-day (7×24) services in light of higher security impose significant limitations on scalability and otherwise updating and modifying of the different servers. In particular, a file-based web server has to be updated internally to handle extensions to this system. This means shutting down the server for updates, upgrades, and scaling, thereby losing 7×24 availability. Thus the file-based server has become difficult to maintain, extend, and scale, especially as demands for expanded customer services and dynamic real-time content have increased.
This problem is further exacerbated in multi-server environments, also illustrated in FIG. 1. In multi-server environments as illustrated in FIG. 1 having five servers 15.1–15.5, it is necessary to replicate the contents of server 15 onto each of servers 15.1–15.5. Accordingly, this means that copies of all the files 16.1–16.n and executable 18 must be replicated five times for each of servers 15.1–15.5. Similarly, as illustrated, the point-to-point links from servers 15 and 15.1–15.5 to database 17 and content server 19 must be made for each of such servers.
As indicated before, updating and scaling requires internal updates to the web servers, which means that all the computers (servers) must be shut down, negatively impacting 7×24 availability. This also means that it is difficult for businesses to expand and adapt their systems to meet the needs of their customers. Accordingly, there is a need for an alternative system.